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REAL PARTY IN INTEREST 

The real party in interest is Atheros Communications, Inc. 

RELATED APPEALS AND INTERFERENCES 

There are no appeals or interferences that will directly affect, be directly affected by, or 

have a bearing on the Board's decision in this appeal. 

STATUS OF CLAIMS 
Claims 1-37 are pending in the application. Claims 1-37 stand rejected. Claims 1-31 

have been rejected two or more times, and claims 32-37 were finally rejected in the final Office 

Action dated December 29, 2004. The rejection of claims 1-37 is appealed. 



STATUS OF AMENDMENTS 
No amendments have been filed subsequent to the final rejections in the final Office 

Action mailed December 29, 2004. A request for reconsideration was filed on February 25, 2005 

but was not deemed to place the application in condition for allowance, thus resulting in this 

Appeal. 

SUMMARY OF CLAIMED SUB JECT MATTER 

The present invention relates to a Media Access Control (MAC) unit in a 

telecommunications device, and more particularly to a wireless LAN MAC unit in which certain 
frame processing functions are implemented in hardware, rather than, as is conventionally done, 
in software using a central processing unit (CPU) (for example a dedicated MAC unit CPU in a 
network interface card (NIC)) or the like (see FIG. 1, page 3 lines 4-7, page 5, lines 15-18). As 
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set forth in the "objects" of the invention: "it is an object of this invention to provide a MAC 

unit with hardware components for selected time-critical functions It is a further object to 

provide a MAC unit that eliminates or substantially reduces the need for a MAC CPU." (see 
page 3, lines 9-15). 

In particular, the present invention recognizes that certain "time-critical" functions may 
need to be carried out on the scale of tens of microseconds for proper frame separation, whereas 
other functions need only be carried out on the scale of milliseconds or even seconds, (see page 
6, lines 17-20). In one example, these time-critical frame processing functions include a portion 
of the frame level protocol manager (FLPM) sub-layer 52 of the MAC layer of frame processing. 
The particular "time critical" frame processing functions are described in connection with the 
diagram in FIG. 5, and at page 6, line 21 to page 7, line 16. These "time critical" frame 
processing functions are mapped to certain hardware blocks in FIG. 6 as described at page 8, line 
7 to page 10, line 6. 

According to one example of the invention, and as set forth in independent claims 1 and 
16, the hardware MAC system is disposed in a communication path between a host CPU 36 and 
a network 34 (see FIG. 3). In order to implement time-critical MAC layer functions without a 
CPU and associated software, the hardware MAC unit includes a buffer interface (100) that 
sends frames to the host CPU (36) and receives frames from the host CPU (36), a frame 
transmitter that includes a transmit buffer (102) that receives frames from the buffer interface 
(100) and sends frames to the network (34), and a frame receiver that includes a receive buffer 
(104) that receives frames from the network (34) and sends frames to the buffer interface (100). 
(see also page 7, line 17 to page 8, line 6). 
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In addition, as set forth in claim 1, the hardware MAC unit includes an encryption / 
decryption block (106) that sends and receives frames between the transmit buffer and the 
receive buffer, (see page 7, line 23 to page 8, line 1). 

As further set forth in claims 3, 10 and 17 (which depend from independent claims 1 and 
16), the frame transmitter includes a transmit state machine (108), and the frame receiver 
includes a receive state machine (1 10). These components are further useful for performing 
time-critical MAC layer functions in hardware, (see page 8 lines 9 to 22 for example). 

As set forth in claims 4, 1 1 and 18 (which depend from independent claims 1 and 16), the 
frame receiver includes a filtering block for filtering frames (110, see page 8, lines 20-22). 

As set forth in claims 5, 12 and 19 (which depend from independent claims 1 and 16), the 
frame receiver includes a retry operations block for determining when retransmission of a 
particular frame is needed (1 10, see page 8, lines 9-11 and page 9, lines 1-5). 

As set forth in claims 6, 13 and 20 (which depend from independent claims 1 and 16),the 
frame transmitter includes an acknowledgement block for determining when a frame was 
anticipated and sending an acknowledgement message corresponding thereto (109, see page 8, 
lines 18-20 and page 9, lines 1-5). 

As set forth in claims 7, 14 and 21 (which depend from independent claims 1 and 16), the 
frame transmitter includes a special frames generation block (108, see page 9, line 17 to page 10, 
line 6). 

As set forth in claims 8, 15 and 22 (which depend from claims 7, 14 and 21, respectively), 
the special frames generation block include means for generating beacons (108 and 1 14, see page 
9, line 17 to page 10, line 6). 
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As further set forth in independent claim 2, MAC layer processing of frames is performed 
using operations implemented by hardware in an integrated circuit. For example, the hardware 
frames processing includes time-critical functions 54 of the MAC layer 46 (see FIG. 4, page 5, 
line 19 to page 6, line 20). As specifically required by claim 2, the time critical functions include: 
(1) sending an outgoing frame corresponding to the incoming frame to the host (block 82 in FIG. 
5); (2) formulating time-critical responses (block 74 of FIG. 5); (3) accumulating statistics 
(block 76 of FIG. 5); and (4) updating a media access control state (block 78 of FIG. 5). (see 
also page 7, lines 1 to 16). 

As set forth in claims 24 and 25 (which depend from independent claim 2), the time 
critical functions further include "formulating an outgoing response frame" (block 80 in FIG. 5) 
and "transmitting the response frame to the network" (block 82 in FIG. 5, see also page 7, lines 
10-13). 

As set forth in claim 26 (which depends from claim 25), the hardware operations must 
further include "generating a special frame" (block 84 in FIG. 5, see also page 7, lines 13-14). 

As set forth in claim 27 (which depends from claim 26), the hardware operation of 
generating a special frame includes generating a beacon (block 84, see page 10, lines 1-3). 

As set forth in claim 30 (which depends from independent claim 2), the time-critical 
functions implemented by hardware operations includes determining whether retransmission of a 
particular frame is needed (blocks 70 and 74 in FIG. 5, see page 8, lines 9-11 and page 9, lines 1- 
5). 

As set forth in claim 31 (which depends from independent claim 2), the hardware 
operations include determining when a frame was anticipated and sending an acknowledgement 
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message corresponding thereto (blocks 72 and 74 in FIG. 5; see page 8, lines 18-20, page 9, lines 
1-5). . . 

As set forth in claims 32-34 (which depend from claims 1,16 and 2, respectively), the 
hardware MAC unit is limited to implementing certain functions of a MAC sublayer in 
accordance with IEEE 802.1 1 (see page 1, lines 13-23, and page 5 line 19 to page 6, line 20). 

As set forth in claims 35-37 (which depend from claims 1,16 and 2, respectively), the 
enumerated frame processing functions and components are implemented together in a single 
integrated circuit, (see page 10, lines 7-10). 

GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

All claims 1-37 have been finally rejected under 35 U.S.C. § 102(e) as being anticipated 

by a single prior art reference, U.S. Patent No, 6,341,145 to Hioe et al. {"Hioe"). Appellants 
respectfully submit that these rejections are in error for multiple reasons, and seek review of the 
following independently reversible grounds: 

• Whether Hioe discloses a hardware MAC system comprising a frame transmitter that 
includes a transmit buffer that receives frames from the buffer interface and sends frames to 
the network, and a frame receiver that includes a receive buffer that receives frames from the 
network and sends frames to the buffer interface as required by claims 1 and 16. 

• Whether Hioe discloses a hardware MAC system including an encryption / decryption block 
that sends and receives frames between the transmit buffer and the receive buffer as required 
by claim 1. 
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• Whether Hioe discloses a hardware MAC system whose frame transmitter includes a transmit 
state machine, and whose frame receiver includes a receive state machine as required by 
claims 3, 10 and 17. 

• Whether Hioe discloses a hardware MAC system whose frame receiver includes a filtering 
block for filtering frames as required by claims 4, 1 1 and 18. 

• Whether Hioe discloses a hardware MAC system whose frame receiver includes a retry 
operations block for determining when retransmission of a particular frame is needed as 
required by claims 5,12 and 19. 

• Whether Hioe discloses a hardware MAC system whose frame transmitter includes an 
acknowledgement block for determining when a frame was anticipated and sending an 
acknowledgement message corresponding thereto as required by claims 6, 13 and 20. 

• Whether Hioe discloses a hardware MAC system whose frame transmitter includes a special 
frames generation block as required by claims 7, 14 and 21. 

• Whether Hioe discloses a hardware MAC system whose frame transmitter includes a special 
frames generation block, the special frames generation block including means for generating 
beacons as required by claims 8, 15 and 22. 

• Whether Hioe discloses a method for processing frames in a MAC layer using operations 
implemented by hardware in an integrated circuit, the hardware frames processing including 
time-critical functions, the time critical functions including: (1) sending an outgoing frame 
corresponding to the incoming frame to the host; (2) formulating time-critical responses; (3) 
accumulating statistics; and (4) updating a media access control state, as required by 
independent claim 2. 
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• Whether Hioe discloses hardware frames processing of time-critical functions in a MAC 
layer, the time critical functions further including "formulating an outgoing response frame" 
and "transmitting the response frame to the network" as required by claims 24 and 25. 

• Whether Hioe discloses hardware frames processing of time-critical functions in a MAC 
layer, the hardware operations further include "generating a special frame" as set forth in 
claim 26. 

• Whether Hioe discloses hardware frames processing of time-critical functions in a MAC 
layer, the hardware operation of generating a special frame including generating a beacon as 
required by claim 27. 

• Whether Hioe discloses hardware frames processing of time-critical functions in a MAC 
layer, the time-critical functions implemented by hardware operations including determining 
whether retransmission of a particular frame is needed as set forth in claim 30. 

• Whether Hioe discloses hardware frames processing of time-critical functions in a MAC 
layer, the time-critical functions implemented by hardware operations including determining 
when a frame was anticipated and sending an acknowledgement message corresponding 
thereto as required by claim 31. 

• Whether Hioe discloses a hardware MAC system with enumerated blocks and functions that 
implement certain functions of a MAC sublayer in accordance with IEEE 802.1 1 as required 
by claims 32-34. 

• Whether Hioe discloses implementing the enumerated functions and components of claims 1, 
16 and 2 together in a single integrated circuit as set forth in claims 35-37. 
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ARGUMENT 

The bases for the Examiner's rejections using Hioe have evolved over time, but now 
appear to be primarily a combination of various theories of inherency and opinions of what claim 
limitations are significant enough to be considered. Meanwhile, a cited prior art reference 
anticipates a claimed invention under 35 U.S.C. §102 only if every element of the claimed 
invention is identically shown in the single reference, arranged as they are in the claims. MPEP 
§2131; In re Bond, 910 F.2d 831, 832, 15 USPQ 2d 1566, 1567 (Fed. Cir. 1990). Each and 
every limitation of the claimed invention is significant and must be found in the single cited prior 
art reference. In re Donohue, 766 F.2d 531, 534, 226 USPQ 619, 621 (Fed. Cir. 1985). Where 
limitations are not explicitly present, "[t]o establish inherency, the extrinsic evidence 'must make 
clear that the missing descriptive matter is necessarily present in the thing described in the 
reference, and that it would be so recognized by persons of ordinary skill. Inherency, however, 
may not be established by probabilities or possibilities. The mere fact that a certain thing may 
result from a given set of circumstances is not sufficient.'" In re Robertson, 169 F.3d 743, 745, 
49 USPQ2d 1949, 1950-51 (Fed. Cir. 1999) (citations omitted). 

As set forth more fully below, Applicants respectfully traverse the § 102 rejection of the 
claims because every element of the claimed invention is not identically shown in Hioe, and/or 
arranged as they are required by the claims, and one skilled in the art would not necessarily 
believe that the missing limitations are inherently present in Hioe, 

Summary Description Of Single Cited Reference (Hioe) 

The Office Action relies on only a single prior art reference (Hioe) for meeting all the 
limitations of the pending claims. Accordingly, a thorough summary of this reference is 
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provided first. It should be noted at the outset, however, that Hioe mentions nothing whatsoever 
about MAC layer processing of frames, or about any known wireless communications protocols 
such as IEEE 802.1 1 which specify such required frame processing. Rather, in general, Hioe 
merely discloses a broadband digital radio system, and in particular a terminal for use in such a 
system. Hioe aims at setting a transmission condition for communications between terminals 
based on a measure of the line quality of the channels being used. (col. 1, lines 7-12). 

FIG. 3 illustrates a block diagram of a terminal in accordance with Hioe's teachings and 
objects. For convenience, FIG. 3 of Hioe is reproduced below. 
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With respect to "transmission side" elements 302-310 of packet processing section 210 

and modulation section 203, Hioe teaches, at col. 6 line 54 to col. 7 line 9 (emphasis added), that: 

In the input interface 300, data are arranged in order of arrival for 
each category , referring to the header information, and temporarily held . 
The data from the input interface 300 is transmitted to a wireless- 
packeting block (WeP) 302 from the input interface 300 at a 
predetermined timing and incorporated into a packet for radio 
transmission. Coding for radio transmission, error control coding, and 
encryption if necessary are applied to the packeted data by an encoding 
block (eC) 304. Then, a digital signal is converted into an analog signal by 
a baseband modulation block (BB-mod) 306 and an analog waveform is 
generated. The generated analog signal is modulated into an intermediate 
frequency band by an intermediate frequency modulation block (IF-mod) 
308 and at the same time, the frequency components other than the 
occupied narrow frequency band are suppressed. An intermediate 
frequency signal is upconverted to a radio frequency by a radio frequency 
modulation block (RF-mod) 310 where the signal power is amplified up to 
the transmission level and the frequency components other than the 
occupied wide frequency band are suppressed. The amplified signal is 
radiated from a transmission antenna (TXN) 312. 

As should be clear, Hioe's elements 302-3 10 merely receive data from a buffer (i.e. 
input interface 300, the alleged "buffer interface") at a predetermined timing and convert the data 
into analog waveforms. Elements 306-310 all produce analog waveforms from digital data. And 
elements 302 and 304 work with digital data at a predetermined timing and thus do not need or 
allow for any buffering operation. The overall operation of Hioe's alleged "frame transmitter" is 
to read data from buffer 300 and propagate it in a serial fashion or "peristaltically" through a 
transmit chain comprising elements 302-310. 

This synchronous and serial transfer of data from buffer 300 through elements 302 and 
304 is further underscored by additional disclosures within Hioe. For example, FIG. 7 
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(reproduced below), and corresponding descriptions make clear that even during so-called 
"processing" or "packetizing" of the data, there is no "buffering" operation performed. 



302 > 



FROM INPUT INTERFACE 300 



FIG. 7 
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CONTROL SECTION 370 



In the corresponding description of FIG. 7, Hioe teaches at col. 10, lines 22-42 (emphasis 



added): 



FIG. 7 shows an embodiment of the circuit of the wireless packeting block 
302. A header information memory 714 stores the header information for each 
transmission channel. The header information includes the address of the 
transmission-side terminal and category of the transmission. The category is used 
to judge whether or not it is necessary to request retransmission of the received 
wireless packet when any data error is present in the wireless packet. 

An instruction output from the block control circuit 370 of the control 
section 360 to designate the wireless packet length to each transmission channel is 
temporarily held in an instruction register 710. A control circuit 712 outputs an 
instruction of data transmission to the input interface 300, the memory address of 
the header to the header information memory 714, and a selection signal to a 
multiplexer 716 in accordance with the instruction of the control instruction 
register 710. Header information is first output to and then, data is output to the 
next-stage circuit in accordance with the control by the control circuit 712 
synchronously with a clock signal and thereby, a wireless packet is formed . 
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As should be clear from these descriptions, when forming a packet, data is merely shifted 
from buffer 300 through multiplexer 716 synchronously with a clock signal . Accordingly, 
there is no need to further buffer the data that is received from buffer 300. In accordance with 
Hioe's object to account for channel quality, Hioe allows for the length of the wireless packet to 
be changed, which is done by controlling the operation of multiplexer 716 to extract an 
appropriate amount of data from buffer 300 for the given channel. 

No further buffering is required downstream from block 302. This is further underscored 
by additional teachings in Hioe, In particular, Hioe makes clear that no buffering of data is 
required during modulation of the digital data into an analog waveform, as described in 
connection with the modulation process and FIGs. 9a and 9b (reproduced below). 
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In connection with these figures, Hioe teaches at col. 11, line 56 to col. 12, line 26 
(emphasis added): 

As described above, it is necessary to simultaneously execute the 
operations of the baseband modulation block 306 for executing analog-signal 
processing and the intermediate frequency modulation block 308 which are 
provided correspondingly to a narrowband channel. FIG. 9A schematically shows 
the transmission unit of FIG. 3, where the analog modulation section is shown in 
more detail. The baseband modulation block 306 is provided with a sorter 
(ChS) 900 , namely a series/parallel converter circuit, in order to transmit the 
data corresponding to each transmission channel in parallel. Wireless packets 
are arranged for each transmission channel by the sorter 900. Each transmission 
channel is synchronously input to a baseband demodulator corresponding to 
each transmission channel from the sorter 900 and thereby, converted into 
an analog signal in parallel and modulated to a high frequency . 

FIG. 9B is a block diagram of a circuit for executing modulation. In the 
sorter 900, a control circuit 912 controls a sorter circuit 914 and performs 
classification of wireless packets and the conversion from series to parallel in 
accordance with an instruction output from the block control circuit 370 of the 
control section 360 and stored in a channel control register 910. The output of 
the sorter circuit 914 is input to baseband modulation (BB-mod) circuits 926- 
1 to 926-n and converted into an analog signal by using a modulation code 
read out of a modulation code memory (mod code mem) 924 and thereby 
executing digital-analog conversion . 

Then, the analog signal is converted into a signal in an intermediate 
frequency band by the intermediate frequency modulation circuit block 308. The 
analog signal output from the baseband modulation circuit is modulated to an 
intermediate frequency in a narrow intermediate frequency band by a series 
circuit of a hybrid circuit 936 and a band-pass filter 938 in accordance with a 
local oscillation signal output by a multiple-frequency local oscillator 934. The 
outputs of the series circuits are combined by a power combiner circuit 940 and 
output to the radio frequency modulation block 310. 

From these descriptions, it is clear that serial data from packeting block 302 and error 
correction block 304, which includes packets for all channels in one continuous serial stream, is 
merely demultiplexed into channels by channel sorter 900 so that modulation of carriers for each 
channel can occur in parallel. This operation is performed "synchronously" according to clocks 
and signals from control circuit 912, thus reinforcing the "peristaltic" nature of the system. The 
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sorter 900 does not itself create parallel words, rather it transmits bits serially to different 
modulators in a parallel fashion. A plurality of bits for a given channel is then used by the 
individual channel modulators 926-1 to 926-n to lookup a code for performing the appropriate 
digital-to-analog conversion of the digital data, thus performing baseband modulation (e.g. a 
form of pulse code modulation). 

Hioe does not provide any significant additional detail regarding the "receive-side" 
blocks or operation thereof, so it can be assumed that it merely provides an inverse operation of 
the "transmit-side" blocks. 



Hioe Does Not Explicitly or Inherently Include a Transmit Buffer or Receive Buffer As 
Required By Independent Claims 1 and 16 

Independent claims 1 and 16 both require: 

a buffer interface that sends frames to the host central 
processing unit and receives frames from the host central 
processing unit; 

a frame transmitter that includes a transmit buffer that 

receives frames from the buffer interface and sends frames to the 

network; 

a frame receiver that includes a receive buffer that 
receives frames from the network and sends frames to the buffer 
interface . . 

In the first Office Action mailed May 19, 2004, the Examiner stated that Hioe's block 
203 corresponded to the claimed frame transmitter, and that elements 306-310 corresponded to 
the claimed transmit buffer. The first Office Action also stated that Hioe's block 205 
corresponded to the claimed frame receiver, and that elements 336-340 corresponded to the 
claimed receive buffer. (Office Action at 4.) The Office Action made no mention of any 
reliance on any theory of inherency. 
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After Applicants showed how this position was incorrect without amending the claim, the 
Examiner revised the rejection to state that Hioe's blocks 203 and 210 or (302-303) [sic] together 
"clearly" corresponded to the claimed frame transmitter, with elements 302 and 304 
corresponding to the claimed transmit buffer. The Examiner further revised the rejection to state 
that Hioe's blocks 205 and 206 "clearly" correspond to the claimed frame receiver, with 
elements 332 and 334 together comprising the claimed receive buffer. (Final Office Action at 
12-13). The Final Office Action also made no reference to any theory of inherency, taking the 
position that these limitations were "clearly" anticipated by Hioe. 

In response to the Final Office Action, Appellants again convincingly showed that none 
of the asserted elements 302, 304, 332 or 334 could be considered a "buffer." Rather than 
withdrawing the rejection, in remarks accompanying the Advisory Action, the Examiner yet 
again revised the grounds for t he rejection, and for th e first time st ated a theory of inherency. 1 
The final revised ground for rejection (see Advisory Action at 3, emphasis added) is that 



WeP 302 or-BB-mod-306 can be corresponded to the claimed 'transmit 
buffer' because at WeP 302, the received packet must be buffered 
before incorporating (adding packet header or necessary information for 
routing or transmitting as known packeting processing art) and because at 
BB-mod 306, in order to convert a digital signal into an analog signal, 
the digital signal must be implicitly buffered , then converted into an 
analog waveform. This is an implicit or inherent function of a baseband 
modulator in a telecommunication system (see Fig. 9a and the 
corresponding description at col. 11, line 60 to col. 12, line 4 for an 
explanation of sorter (ChS) 900). 



i 



Appellants object to the untimely inclusion of this new ground of rejection after 
Appellants' response to the final office action, and do not believe it can be properly considered 
without reopening prosecution (see MPEP 2112). Nevertheless, for completeness, this new 
ground will be addressed here. Appellants also understand this new ground as a final 
admission by the Examiner that neither of the claimed buffers are explicitly present in Hioe, 
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Addressing this final revised ground for rejection, Appellants respectfully submit that 
neither Hioe's wireless packeting block WeP 302 nor baseband modulator block 306 inherently 
include a "transmit buffer" as required by independent claims 1 and 16. 

"To establish inherency, the extrinsic evidence 'must make clear that the missing 
descriptive matter is necessarily present in the thing described in the reference, and that it would 

be so recognized by persons of ordinary skill In re Robertson, 169 F.3d 743, 745, 49 

USPQ2d 1949, 1950-51 (Fed. Cir. 1999) (citations omitted). As set forth in the summary 
description of Hioe's teachings, no buffer is needed (i.e. not necessarily present) in blocks WeP 
302 or 306. More particularly, by operating at a predetermined synchronous timing in which 
data moves peristaltically or serially through Hioe's transmit chain, one skilled in the art would 
recognize that the data for the wireless packets is not necessarily buffered either in WeP 302 or 
BB-mod306. 2 

First, with respect to block WeP 302, FIG. 7 of Hioe and the associated descriptions 
make clear that data from buffer 300 is synchronously clocked into a serial stream by multiplexer 
716, which operates under control of control circuit 712 to form a wireless packet of appropriate 
length as a string of serial bits, and to serially append header information thereto. Nowhere does 
Hioe disclose or suggest that the data from buffer 300 is further buffered in block WeP 302, and 
such a suggestion would be counterintuitive to the "synchronous" nature of the data flow 
described by Hioe. Accordingly, one skilled in the art would not consider a buffer to be 
necessarily present in WeP block 302. 

2 Although not necessary to define over Hioe, Appellants note that the clear language of 
the claims requires the buffers in both the receiver and transmitter to be capable of storing 
frames . 
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With respect to block BB-mod 306, FIGs. 9a and 9b of Hioe and the associated 
descriptions further underscore the synchronous and peristaltic operation of the transmit chain. 
The grounds for rejection stated in the Advisory Action appears to assert that before modulation 
can occur, data modulating the signal must be buffered. However, Hioe merely teaches that this 
block performs a lookup of a code in code memory 924 to perform digital-to-analog conversion 
(i.e. a form of pulse code modulation). One skilled in the art would not consider a D-A converter 
or its associated input to be a buffer. Moreover, all that would be required to perform such a 
lookup operation would be to latch a predetermined set of bits of the data at an input of the D-A 
converter or lookup table. Such a latch operation would not be considered equivalent to a buffer 
by those skilled in the art. 

The same reasoning above with respect to the claimed transmit buffer also applies to the 
claimed receive buffer, and so Hioe also fails to expressly or inherently a receive buffer as 
required by the claims. 

For at least these reasons, Appellants submit that claims 1 and 16 patentably define over 
Hioe and the § 102 rejection of these claims, as well as claims 3-15, 32 and 35 that depend from 
claim 1, and claims 17-23, 33 and 36 that depend from 16, should be withdrawn. 

Hioe Does Not Explicitly or Inherently Include an Encryption/Decryption Block As 
Further Required By Independent Claim 1 

In addition to the missing subject matter that is common with claim 16 as set forth above, 
claim 1 requires an encryption / decryption block that "sends and receives frames between the 
transmit buffer and the receive buffer." 
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This subject matter is not taught or suggested by Hioe, at least because Hioe does not 
disclose or suggest a transmit buffer or receive buffer as required by the explicit limitations of 
claim 1. Specifically, Hioe's encryption block 304 (part of the alleged "encryption/decryption 
block") receives data from WeP block 302 and sends data to BB-mod block 306, neither of which 
would be considered a buffer by those skilled in the art. Decryption block 334 receives data from 
BB-dem block 336 and sends data to WdP block 332, neither of which would be considered a 
buffer by those skilled in the art. Accordingly, Hioe cannot possibly include an encryption / 
decryption block that "sends and receives frames between the transmit buffer and the receive 
buffer ." 

Moreover, the Office Action alleges that elements 304 and 334 together comprise the 
claimed encryption/decryption block. However, there is no single element in Hioe that both 
encrypts and decrypts frames. Rather, Hioe teaches separate blocks 304 and 334 for encryption 
and decryption, respectively. Accordingly, Hioe does not explicitly meet the limitations of the 
claims. 

The Final Office Action did not supply any theory or attempt to base this rejection on 
inherency. However, the Advisory Action appears to set forth a new theory. 4 The Advisory 
Action states (at 4) that: 

Figure 3 is just a mere functional blocks of the disclosed system for easy 
understanding. In a real telecommunications system, the encryption/decryption 
device is a single piece of equipment having cards for performing encrypting the 



Moreover, neither of these blocks inherently includes a buffer for reasons set forth above. 

4 For similar reasons to those set forth above, Appellants object to the untimely 
introduction for a new grounds of rejection and respectfully submit that these new grounds for 
rejection should not be considered. Nevertheless, for completeness, this newly revised 
grounds for rejection will be addressed here. 
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received data in the transmission side and cards for performing decrypting the 
received data in the reception side. This conclusion is from Examiner's own 
experience while serving more than six year as S ATCOM technician and/or 
Krypto specialist in the US Army dealing with uploading and maintaining 
encryption/decryption device (KG- 194 or KG-81) in a tactical satellite 
communication system (AN-GSC 86). There are different type of Krypto devices. 
However, the functional structures and operational principles are the same. Thus, 
contradistinction to the Applicants' argument Hioe et al. does indeed disclose the 
disputed limitations. 

It is not clear from this new grounds whether it is intended to set forth a theory of 
inherency or a theory of obviousness. If the latter, Appellants respectfully object that the prior art 
on which it is based has not been made of record. If the former, Appellants respectfully submit 
that it proves nothing about what is necessarily included in Hioe's system, which would be 
required to support a theory of inherency. In a transceiver system having both transmission and 
reception components, it may be indeed possible to combine certain of such separate components 
into single blocks for efficiency or other reasons. However, those skilled in the art know that it is 
not necessary , and there may be very practical considerations why such combination cannot be 
done. Indeed, the Examiner's cited KG- 194 WALBURN-class trunk cryptologic equipment also 
provides separate encryption and decryption modules which operate independently and 
contemporaneously to afford high data rate full-duplex communication. The Examiner's own 
experience thus demonstrates that one skilled in the art would not consider Hioe to necessarily 
combine encryption and decryption components into a single block. 

Accordingly, independent claim 1 further patentably defines over Hioe for at least this 
additional reason, and the § 102 rejection of the claim should be withdrawn. 
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Hioe Does Not Disclose Implementing Time-Critical Processing Functions Using Hardware 
Operations As Required By Independent Claim 2 

Independent claim 2 requires 

processing, using operations implemented by hardware in an 
integrated circuit , the incoming frame for time-critical functions , the 

time critical functions including: 

sending an outgoing frame corresponding to the incoming frame 
to the host; 

formulating time-critical responses; 

accumulating statistics; and 

updating a media access control state. 

Independent claim 2 requires that the method include specifically enumerated time- 
critical functions that are implemented as hardware operations in an integrated circuit . In 

contrast to the explicit requirements of independent claim 2, the Final Office Action relies on 
passages of Hioe that describe operations of a "channel control processor" (CCP) 368, which 
operations are clearly software executing on a processor, not as hardware operations in an 
integrated circuit. 5 

Moreover, independent claim 2 sets forth enumerated processing functions for an 
incoming frame . Meanwhile, the cited operations of Hioe merely relate to determining line 
transmission conditions according to various status information and controlling the transmission 
unit in accordance therewith. Specifically, the cited passages teach as follows (col. 7, lines 35- 
58) (emphasis added), with the claim limitations they are alleged to meet in brackets: 



The Advisory Action states that "Hioe et al patent implicitly and inherently anticipated 
this claimed limitation." (page 4) However, the Examiner has never supplied any theory of 
inherency, and even if it had been done with the Advisory Action, such untimely-introduced 
theory should not be considered. 
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[formulating time-critical responses] 

The control section 360 will be described as follows. 

The information of the data stored in the input interface 300 is recorded in an 

input buffer status memory (BSM) 362. A channel control processor (CCP) 368 

can recognize a necessary communication demand from the presence or 

absence of the data stored in the input interface 300 for each transmission 

condition category by reading data from the input buffer status memory 362 . 

[accumulating statistics] 

The latest line-quality information is included in the control information 
transmitted from the communication party through the control channel 208. The 
line-quality information is extracted from the control information by the output 
interface 330 and recorded in the line quality memory (CQM) 364. An algorithm 
for determining the transmission channels and transmission conditions, which will 
be described later, is stored in a channel setting rule memory (CST) 366. 

[updating a media access control state] 

The channel control processor 368 determines transmission conditions based 
on the communication demand stored in the input buffer status memory 362 
and the information on the line quality stored in the line quality memory 364 
in accordance with the channel setting rules stored in the channel setting rule 
memory 366 . A block control circuit (BCC) 370 controls the transmission unit in 
accordance with the determined transmission conditions. 



Hioe teaches nothing about processing of incoming frames within control section 360, 
much less the required steps of : 

1. sending an outgoing frame corresponding to the incoming frame to the host; 

2. formulating time-critical responses; 

3. accumulating statistics; and 

4. updating a media access control state. 

Because Hioe does not teach, and in fact teaches away from, the invention required in 
independent claim 2, including the explicit limitation of performing time-critical functions for 
processing an incoming frame that are implemented as hardware operations in an 
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integrated circuit , the § 102 rejection of this claim, along with claims 24-31 that depend 
therefrom, should be withdrawn. 6 



Hioe Does Not Disclose A Transmit or Receive State Machine As Required Bv Dependent 
Claims 3. 10 and 17 

Claims 3 and 10 depend from independent claim 1 and claim 17 depends from 
independent claim 16. These claims patentably define over Hioe at least by virtue of their 
dependence on claims 1 and 16 for the reasons set forth above. Moreover, each of these claims 
recite additional subject matter that further patentably distinguish them from Hioe. 

The Office Action alleges that the claimed frame transmitter is allegedly met by packet 
processing section 210 and modulation section 203, and the claimed frame receiver is allegedly 
met by error detection/correction section 206 and demodulation section 205. Meanwhile, each of 
these claims further limit the structure of the claimed frame transmitter and receiver to even 
further distinguish them from Hioe's structure. 

Specifically, claims 3, 10 and 17 require that the frame transmitter includes a transmit 
state machine , and the frame receiver includes a receive state machine . The Office Action 
alleges that these elements are met by transmit antenna 312 and reception antenna 342, 



The Final Office Action takes the completely irrelevant position (page 14) that "the 
specification does not disclose [that this limitation] is a novel and unobvious feature/' 
Appellants respectfully submit that a rejection based on § 102 requires a comparison between the 
express limitations of the claim to the cited reference. If a limitation is not found in the reference, 
the rejection is improper and should be withdrawn. All claim limitations must be considered 
regardless of any conjecture about what the specification opines or does not opine about their 
novelty. In any event, quite contrary to the Office Action's allegation, the application repeatedly 
refers to the hardware implementation of time-critical functions as an important feature and 
object of the invention. See, for example, the specification passages cited in the summary above, 
as well as the very title of the invention: HARDWARE MAC. 
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respectively, neither of which are in the alleged frame transmitter or receiver. Moreover, it is 
submitted that one skilled in the art would not consider an antenna to be equivalent to a state 
machine . 

For at least these additional reasons, claims 3, 10 and 17 further patentably define over 
Hioe and the rejections thereof should be withdrawn. 

Hioe Does Not Disclose A Frame Filtering Block In a Frame Receiver As Required By 
Dependent Claims 4, 11 and 18 

Claims 4 and 1 1 depend from independent claim 1 and claim 18 depends from 
independent claim 16. These claims patentably define over Hioe at least by virtue of their 
dependence on claims 1 and 16 for reasons set forth above. Moreover, each of these claims 
recite additional subject matter that further patentably distinguish them from Hioe. 

The Office Action alleges that the claimed frame receiver is allegedly met by error 
detection/correction section 206 and demodulation section 205. Meanwhile, each of these claims 
further limit the structure of the claimed frame receiver to even further distinguish them from - 
Hioe's structure. 

Specifically, claims 4, 1 1 and 18 require that the frame receiver includes a filtering block 
for filtering frames . The Office Action alleges that Hioe's band-pass filters 1038 correspond to 
the claimed filtering block. However, these filters are described as being part of IF-dem block 
338, and clearly operate to limit an analog signal to a particular pass-band, and as such do not 
know or care about frames, and thus cannot filter such. 

The Advisory Action admits (at page 6) that "It is undisputed that the signals are filtered 
in analog forms [in Hioe's system]." The Advisory Action continues: 
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However, the filtered signals are converted into digital signals (frames) In 

response to applicant's argument that the references fail to show certain features 
of applicant's invention, it is noted that the features upon which applicant relies in 
the arguments are not recited in the rejected claim(s). 

This argument is unsound, because by logical extension any analog filter in a wireless 
communication path would similarly "filter frames." To the contrary, the clear language of the 
claim requires the filter to operate on frames, and not any portions or representations thereof. 
Claims 4, 1 1 and 18 further limit independent claims 1 and 16, and require that the claimed 
filtering block is part of the claimed "frame receiver" that "receives frames from the network and 
sends frames to the buffer interface" as set forth in claims 1 and 16. The input of the receiver is 
a frame and the output is a frame, and in the process the frames are filtered. Accordingly, by 
mere operation, the filter must operate on frames. One skilled in the art would not consider an 
analog filter to be a frame filter. 

For at least these additional reasons, claims 4, 1 1 and 18 further paten tably define over 
Hioe and the rejections thereof should be withdrawn. . _ . ... ... 

Hioe Does Not Disclose A Retry Operations Block In A Frame Receiver As Required By 
Dependent Claims 5, 12 and 19 

Claims 5 and 12 depend from independent claim 1 and claim 19 depends from 
independent claim 16. These claims patentably define over Hioe at least by virtue of their 
dependence on claims 1 and 16 for reasons set forth above. Moreover, each of these claims 
recite additional subject matter that further patentably distinguish them from Hioe. 
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The Office Action alleges that the claimed frame receiver is allegedly met by error 
detection/correction section 206 and demodulation section 205. Meanwhile, each of these claims 
further limit the structure of the claimed frame receiver to even further distinguish them from 
Hioe's structure. 

Specifically, claims 5,12 and 19 require that the frame receiver includes a retry 
operations block for determining when retransmission of a particular frame is needed. The 
Office Action points to col. 9, lines 41-62, and col. 10, lines 23-30, which refer to operations of 
control section 360 and wireless packeting block 302 , not the alleged frame receiver 
(demodulation block 205 and error detection/correction block 206). Accordingly, even if, 
arguendo, these operations correspond to the claimed retry operations block, they are not 
included in the alleged frame receiver, and thus do not meet the explicit requirements of the 
claims for this reason alone. 

Moreover, col. 9, lines 41-62 merely describe software operations for controlling packet 
length, not for determining whether retransmission of a particular frame is needed. Also, col. 10, 
lines 23-30, merely describe adding header information to a packet, and not determining whether 
retransmission of a particular frame is needed. Accordingly, even if, arguendo, these software 
operations could be considered part of a "frame receiver," they would not meet the explicit 
limitations of the claims. 

The Advisory Action introduced a new line of argument, theorizing at page 7 that 

[t]here are limited ways to combat advert situations such as packet loss or error in 
wireless packet communications. The known ways are automatic retransmission 
request (ARQ), forward error correction (FEC) and the combination of ARQ and 
FEC. Hioe et al patent discloses all known ways at col. 9, lines 41-62 and col. 10, 
lines 23-30. Control circuit 370 of the control section 360 is responsible for 
combating advert situations to include request retransmission of the received 
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wireless packet when any data error is present in the wireless packet (col. 10, lines 
23-30 and thereinafter). 

None of the cited passages supports this new argument. On the contrary, Hioe's control 
section 360 and control circuit 370 merely monitor line status and adjust transmission conditions 
in accordance with line conditions. It uses three techniques to account for line conditions: (1) 
control of error correction code (col. 8, line 31); (2) control of wireless packet length (col. 9, line 
41); and (3) control of aerial path (col. 10, line 48). None of these techniques involves the 
control section or control circuit actually making a determination of whether retransmission of a 
particular frame is needed (these passages have been thoroughly reviewed, and they make no 
mention of ARQ). This determination might be done in Hioe's system by end data terminals, but 
nowhere does Hioe suggest that this is done by software in either control section 360 or circuit 
370. 

For at least these additional reasons, claims 5, 12 and 19 further patentably define over 
Hioe and the rejections thereof should be withdrawn. 

Hioe Does Not Disclose An Acknowledgement Block In A Frame Transmitter As Required 
By Dependent Claims 6, 13 and 20 

Claims 6 and 13 depend from independent claim 1 and claim 20 depends from 
independent claim 16. These claims patentably define over Hioe at least by virtue of their 
dependence on claims 1 and 16 for reasons set forth above. Moreover, each of these claims 
recite additional subject matter that further patentably distinguish them from Hioe. 

The Office Action alleges that the claimed frame transmitter is allegedly met by packet 
processing section 210 and modulation section 203. Meanwhile, each of these claims further 
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limit the structure of the claimed frame transmitter to even further distinguish them from Hioe's 
structure. 

Specifically, claims 6, 13 and 20 require that the frame transmitter includes an 
acknowledgement block for determining when a frame was anticipated and sending an 
acknowledgement message corresponding thereto . The Office Action points to col. 5, lines 
63-66, which refer to operations of control section 204a, not the alleged frame transmitter 
(modulation block 203). Accordingly, even if, arguendo, these operations correspond to the 
claimed acknowledgement block, they are not included in the alleged frame transmitter, and thus 
do not meet the explicit requirements of the claims. 

Moreover, col. 5, lines 63-66 merely suggest sending a test signal for supervising line 
quality, and teaches nothing about sending an acknowledgement message corresponding to 
reception of an anticipated frame , as explicitly required by the claims. Accordingly, even if, 
arguendo, these software operations could be considered part of the frame transmitter, they 
would not meet the further explicit limitations of the claims. 

The Advisory Action (at page 7) responds only to this last point by stating: 

At col. 5, lines 63-66, Hioe et al discloses a feedback loop for cyclically 
supervising the line quality is formed by transmitting data and a test signal and 
returning error rate information of the transmitted data corresponding to the 
claimed limitation. 

However, this passage relates only to Hioe's operation of monitoring a control channel 
and changing transmission conditions in accordance with line quality. There is no 
acknowledgment message sent in connection with the test data or signal. It is just used by the 
control section 204a to adjust the transmission conditions (e.g. data rate, error control method 
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and/or size of wireless packet). Moreover, this position is still inconsistent with the claims 
which require the acknowledgment block to be part of the frame transmitter (which the Office 
Action alleges is met by blocks 203 and 210, not control section 204a). 

For at least these additional reasons, claims 6, 13 and 20 further patentably define over 
Hioe and the rejections thereof should be withdrawn. 

Hioe Does Not Disclose A Special Frames Generation Block In A Frame Transmitter As 
Required By Dependent Claims 7, 14 and 21 

Claims 7 and 14 depend from independent claim 1 and claim 21 depends from 
independent claim 16. These claims patentably define over Hioe at least by virtue of their 
dependence on claims 1 and 16 for reasons set forth above. Moreover, each of these claims 
recite additional subject matter that further patentably distinguish them from Hioe. 

The Office Action alleges that the claimed frame transmitter is allegedly met by packet 
processing section 210 and modulation section 203. Meanwhile, each of these claims further 
limit the structure of the claimed frame transmitter to even further distinguish them from Hioe's 
structure. 

Claims 7, 14 and 21 require that the frame transmitter includes a special frames 
generation block. The Office Action merely points to FIGs. 9 A and 9B, which depict the 
modulation block 203 in detail. Neither of these figures includes any element called a "special 
frames generation block." In fact, this would be unusual, because FIGs. 9A and 9B merely form 
modulated analog waveforms based on received data and do not generate frames at all. 
Accordingly, there is no evidence that Hioe's modulation block 203 includes a special frames 
generation block, much less one that meets the explicit requirements of the claims. 

Kuskinetal. 29 Appeal Brief 

09/663,045 073 1 69-0269870 / ATH-033 

60402628 



In response to this convincing argument, the Advisory Action stated (at page 8): 

Modulation block 203 is corresponding to the claimed limitation in the present 
condition because the claimed limitation of 'a special frames generation block' 
given the broadest reasonable interpretation in consisting with the specification is 
'a frame generation block' corresponding to sorter 900 inside baseband 
modulation block 306 arranged wireless packet for transmission as disclosed at 
col. 11, lines 60-67 and thereinafter. 

As discussed above, sorter 900 merely demultiplexes the serial digital data stream into 
different channels before digital-to-analog conversion. One skilled in the art would not consider 
a demultiplexer to correspond to a frame generator, no matter how broadly the term "frame 
generation block" is interpreted, and so this position is unreasonable. 

For at least these additional reasons, claims 7, 14 and 21 further patentably define over 
Hioe and the rejections thereof should be withdrawn. 

Hioe Does Not Disclose A Means For Generating Beacons In A Special Frames Generation 
Block As Required By Dependent Claims 8, 15 and 22 

Claims 8, 15 and 22 depend from claims 7, 14 and 21, respectively. These claims 
patentably define over Hioe at least by virtue of their dependence on claims 7, 14 and 21 for 
reasons set forth above. Moreover, each of these claims recite additional subject matter that 
further patentably distinguish them from Hioe. 

The Office Action alleges that the claimed "special frames generation block" is allegedly 
met by unspecified portions of modulation section 203 depicted in Figures 9 A and 9B. 
Meanwhile, each of these claims further limit the structure of the claimed frame transmitter to 
even further distinguish them from Hioe's structure. 
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Specifically, claims 8, 15 and 22 further require that the special frames generation block 
include means for generating beacons. The Office Action apparently takes the position that this 
subject matter is inherent in Hioe's CDMA or TDMA system. However, there is no teaching of 
a special frames generation block in modulation section 203 at all, much less one that includes a 
means for generating beacons. 7 Accordingly, there is no evidence that Hioe's modulation block 
203 includes a special frames generation block, much less one that includes means for generating 
beacons as explicitly required by the claims. 

For at least these additional reasons, claims 8, 15 and 22 further patentably define over 
Hioe and the rejections thereof should be withdrawn. 

Hioe Does Not Disclose Hardware Operations For Formulating An Outgoing Response 
Frame As Required By Dependent Claim 24 and 25 

Claims 24 and 25 depend from independent claim 2, and so patentably define over Hioe 
at least by virtue of their dependence on claim 2 for reasons set forth above. Moreover, these 
claims recite additional subject matter that further patentably distinguish them from Hioe. 

Specifically, claims 24 and 25 further require steps of "formulating an outgoing response 
frame" and "transmitting the response frame to the network." The Office Action vaguely points 
to col. 7, lines 35-42 ("and thereinafter") as allegedly meeting these limitations. 

However, these passages merely describe operation of control section 360 to determine 
line quality and transmission conditions. This is then used to adjust a transmission rate and/or 
error correction processing. There is no teaching or suggestion that control section 360 is able to 

7 In particular, there is no "beacon generator" in channel sorter 900, which the Advisory 
Action alleges is the claimed special frames generation block. 

Kuskin et al. 31 Appeal Brief 

09/663,045 073 1 69-0269870 / ATH-033 

60402628 



formulate an outgoing response frame or transmit the response frame to the network , much 
less that these operations are implemented in hardware as required by claims 24 and 25. 

For at least these additional reasons, claims 24 and 25 further patentably define over Hioe 
and the rejections thereof should be withdrawn. 

Hioe Does Not Disclose Hardware Operations For Generating A Special Frame As 
Required By Dependent Claim 26 

Claim 26 depends from claim 25 which has been shown above to patentably define over 
Hioe at least because Hioe does not disclose hardware operations for formulating and 
transmitting an outgoing response frame. Accordingly, claim 26 is patentable for at least this 
reason. 

Claim 26 further requires that the hardware operations include "generating a special 
frame." The Office Action merely points to FIGs. 9 A and 9B, which depict the modulation 
block 203 in detail. Neither of these figures includes any element called a "special frames 
generation block." In fact, this would be unusual, because FIGs. 9A and 9B merely form 
modulated analog waveforms based on received data and do not generate frames at all. 
Accordingly, there is no evidence that Hioe's modulation block 203 includes a special frames 
generation block, much less one that meets the explicit requirements of the claims. 

In response to this convincing argument, the Advisory Action stated (at page 8): 

Modulation block 203 is corresponding to the claimed limitation in the present 
condition because the claimed limitation of 'a special frames generation block' 
given the broadest reasonable interpretation in consisting with the specification is 
'a frame generation block' corresponding to sorter 900 inside baseband 
modulation block 306 arranged wireless packet for transmission as disclosed at 
col. 11, lines 60-67 and thereinafter. 
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As discussed above, sorter 900 merely demultiplexes the serial digital data stream into 
different channels before digital-to-analog conversion. One skilled in the art would not consider 
a demultiplexer to correspond to a frame generator, no matter how broadly the term "frame 
generation block" is interpreted, and so this position is unreasonable. 

For at least these additional reasons, claim 26 further patentably defines over Hioe and 
the rejection thereof should be withdrawn. 

Hioe Does Not Disclose Hardware Operations For Generating Beacons Included In A 
Special Frame As Required By Dependent Claim 27 

Claim 27 depends from claim 26, which has been shown above to patentably define over 
Hioe at least because Hioe does not disclose hardware operations for generating a special frame. 
Accordingly, claim 27 is patentable for at least this reason. 

Moreover, claim 27 further requires that the hardware operation of generating a special 
frame includes generating a beacon. The Office Action apparently takes the position that this 
subject matter is inherentin Hioe\s CT>MA or TDMA system. However, there is no teaching of - 
a special frames generation block in modulation section 203 at all, much less one that includes a 
means for generating beacons. Accordingly, there is no evidence that Hioe's modulation block 
203 includes a special frames generation block, much less one that includes means for generating 
a beacon as explicitly required by the claims. 

For at least these additional reasons, claim 27 further patentably defines over Hioe and 
the rejection thereof should be withdrawn. 

8 In particular, there is no "beacon generator" in channel sorter 900, which the Advisory 
Action alleges is the claimed special frames generation block. 
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Hioe Does Not Disclose Hardware Operations For Determining Whether Retransmission Is 
Needed As Required By Dependent Claim 30 

Claim 30 depends from independent claim 2, and so patentably defines over Hioe at least 
by virtue of its dependence on claim 2, and the reasons set forth above in connection with claim 
2. 

Moreover, claim 30 requires that the time-critical functions implemented by hardware 
operations includes determining whether retransmission of a particular frame is needed . 
The Office Action points to col. 9, lines 41-62, and col. 10, lines 23-30 as allegedly meeting this 
limitation. However, col. 9, lines 41-62 merely describe software operations for controlling 
packet length, not for determining whether retransmission of a particular frame is needed. Also, 
col. 10, lines 23-30, merely describe adding header information to a packet, and not for 
performing the actual determination of whether retransmission of a particular frame is needed. 

The Advisory Action introduced a new line of argument, theorizing at page 7 that 

[t]here are limited ways to combat advert situations such as packet loss or error in 
wireless packet.communications. The known ways are automatic retransmission — - 
request (ARQ), forward error correction (FEC) and the combination of ARQ and 
FEC. Hioe et al patent discloses all known ways at col. 9, lines 41-62 and col. 10, 
lines 23-30. Control circuit 370 of the control section 360 is responsible for 
combating advert situations to include request retransmission of the received 
wireless packet when any data error is present in the wireless packet (col. 10, lines 
23-30 and thereinafter). 

None of the cited passages supports a rejection based on this new argument. On the 
contrary, Hioe's control section 360 and control circuit 370 merely monitor line status and adjust 
transmission conditions in accordance with line conditions. It uses three techniques to account 
for line conditions: (1) control of error correction code (col. 8, line 31); (2) control of wireless 
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packet length (col. 9, line 41); and (3) control of aerial path (col. 10, line 48). None of these 
techniques involves the control section or control circuit actually making a determination of 
whether retransmission of a particular frame is needed (moreover, these passages have been 
thoroughly reviewed, and they make no mention of ARQ). Determining and requesting 
retransmission of data might be done in Hioe's system by the end data terminals, but nowhere 
does Hioe suggest that this is done by software in either control section 360 or circuit 370, as 
would be required to at least initially support a rejection of claim 30 (though such operations 
would still be implemented in software, rather than hardware as required by the claim). 

For at least these additional reasons, claim 30 further patentably defines over Hioe and 
the rejections thereof should be withdrawn. 

Hioe Does Not Disclose Hardware Operations For Sending An Acknowledgement For An 
Anticipated Frame As Required By Dependent Claim 31 

Claim 31 depends from independent claim 2, and so patentably defines over Hioe at least 
by virtue of this dependence, and-for the reasons set forth above in connection with claim 2. 

Moreover, claim 3 1 requires that the hardware operations include determining when a 
frame was anticipated and sending an acknowledgement message corresponding thereto . 
The Office Action points to col. 5, lines 63-66, which refer to operations of control section 204a, 
which includes a processor for performing software operations. Accordingly, even if, arguendo, 
these operations correspond to the claimed acknowledgement block, they are not implemented 
by hardware, and thus do not meet the explicit requirements of the claims. 
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Moreover, col. 5, lines 63-66 merely suggest sending a test signal for supervising line 
quality, and teaches nothing about sending an acknowledgement message corresponding to 
reception of an anticipated frame , as explicitly required by the claims. 

The Advisory Action (at page 7) responds only to this last point by stating: 

At col. 5, lines 63-66, Hioe et al discloses a feedback loop for cyclically 
supervising the line quality is formed by transmitting data and a test signal and 
returning error rate information of the transmitted data corresponding to the 
claimed limitation. 

However, this passage relates only to Hioe's operation of monitoring a control channel 
and changing transmission conditions in accordance with line quality. There is no 
acknowledgment message sent in connection with the test data or signal. It is just used by the 
control section 204a to adjust the transmission conditions (e.g. data rate, error control method 
and/or size of wireless p acket). Moreover, this position is still inconsisten t with the claims 
which require the operations to be implemented by hardware (control section 204a includes a 
processor that runs software). 

For at least these additional reasons, claim 3 1 further patentably defines over Hioe and 
the rejection thereof should be withdrawn. 

Hioe Does Not Disclose Hardware For Implementing Functions Of A MAC Sublayer In 
Accordance With IEEE 802.11 As Required By Dependent Claims 32-34 

Claims 32, 33 and 34 depend from claims 1, 16 and 2, respectively. These claims 
patentably define over Hioe at least by virtue of their dependence on claims 1,16 and 2 for 
reasons set forth above. 
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Moreover, each of these claims require implementing certain functions of a MAC 
sublayer in accordance with IEEE 802.11 . 

The Office Action merely points to a passage in Hioe that refers to a CDMA method, and 
states that "it is inherent that the invention is compliant with IEEE 802.1 1." However, this does 
not address the requirements of the claims, which require hardware operations for implementing 
certain functions of a MAC sublayer in accordance with IEEE 802.11 . Merely because 
Hioe's module 201 can theoretically be adapted for use in a IEEE 802.1 1 system does not 
necessarily mean that those same elements of Hioe would implement certain MAC sublayer 
functions of IEEE 802. 1 1 in hardware as required by the claims. As clearly set forth in the 
specification at, for example, page 1, line 13 to page 3, line 7, such functions were typically 
implemented in software prior to the present invention. 

The Advisory Action responds at page 9 that: 

There is no doubt that Hioe et al's system must obey the above [IEEE-802. 1 lb, 
IEEE-802. 1 la and IEEE-802. 1 lg] protocols. The applicable frequency used in 
Hioe et al's system is 2.4 GHz (col. 1, lines 33-35 and thereinafter) reflected that 
of the IEEE 802. 1 1 system. Thus it is concluded that Hioe et al. disclosed the 
claimed limitation. Moreover, IEEE 802. 1 1 is a jointed venture of IEEE task 
force, not invented by the Applicants of the present patent application, made 
available to everyone. 

As to the first position regarding Hioe's "applicable frequency" of 2.4 GHz, this contrasts 
with the operating frequency of 802. 1 la, which is in or around 5.4 GHz. Accordingly, Hioe's 
system is not necessarily applicable to 802. 1 la. Moreover, none of the 802. 1 1 family of 
standards uses either CDMA or TDMA, as is taught by Hioe. In any event, the mere fact that 
Hioe's module 201 is theoretically capable of being adapted for use with an 802.1 1 system, does 
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not necessarily mean that its components can be used to implement MAC layer functions as 
required by the claims. Indeed, there are many possible uses for the unlicensed 2.4 GHz ISM 
(Industrial, Scientific and Medical) spectrum, including microwave ovens, cordless phones and 
Bluetooth transceivers. None of these applications have any need for complying with BEEE 
802.11. 

As for the latter point about IEEE 802.1 1 being "available to everyone," Appellants 
wholeheartedly agree. But that is irrelevant to whether the express claim limitations (which 
include various other limitations in combination with limitations of implementing certain frame 
processing operations of an IEEE 802.1 1 MAC sublayer) are met by Hioe. 

For at least these additional reasons, claims 32-34 further patentably define over Hioe and 
the rejections thereof should be withdrawn. 

Hioe Does Not Disclose Implementing All Components In A Single Integrated Circuit As 
Required By Dependent Claims 35-37 

Claims 35, 36 and 37 depend from claims 1 , 16 and 2, respectively. These claims 
patentably define over Hioe at least by virtue of their dependence on claims 1,16 and 2 for 
reasons set forth above. 

Moreover, each of these claims require implementing their enumerated elements in a 
single integrated circuit . 

The Office Action merely points to a line in Hioe that suggests that the broadband radio 
system is a "digital system" comprising functional blocks. Nothing whatsoever discloses or 
suggests that the entire radio system is implemented as a single integrated circuit , much less 
the specifically enumerated blocks and functions explicitly required by the claims. 
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For at least these additional reasons, claims 35-37 further patentably define over Hioe and 
the rejections thereof should be withdrawn. 

For the foregoing reasons, Appellants respectfully request that all the pending claims be 
deemed allowable by this honorable Board. 

Respectfully submitted, 

PILLSBURY WINTHROP SHAW PITTMAN LLP 



Date: May 12, 2005 
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CLAIMS APPENDIX 

1 . (Previously Presented) A hardware system for performing media access control 
functions between a host central processing unit and a network, the system comprising: 

a buffer interface that sends frames to the host central processing unit and receives frames 
from the host central processing unit; 

a frame transmitter that includes a transmit buffer that receives frames from the buffer 
interface and sends frames to the network; 

a frame receiver that includes a receive buffer that receives frames from the network and 
sends frames to the buffer interface; and 

an encryption/decryption block that sends and receives frames between the transmit 
buffer and the receive buffer. 

2. (Previously Presented) A method for processing frames from a network to a host in a 
media access control layer, the method comprising: 

receiving an incoming frame from the network; and 

processing, using operations implemented by hardware in an integrated circuit, the 
incoming frame for time-critical functions^ the time critical functions including: 

sending an outgoing frame corresponding to the incoming frame to the host; 
formulating time-critical responses; 
accumulating statistics; and 
updating a media access control state. 

3. (Previously Presented) The hardware system according to claim 1 wherein the frame 
transmitter includes a transmit state machine, the frame receiver includes a receive state machine, 
and further including: 

a cyclic redundancy code block that receives frames from the receive state machine and 
the transmit buffer and sends frames to the transmit state machine; and 
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a timer block that controls timing for frames that are respectively sent from and received 
by the system. 

4. (Previously Presented) The hardware system according to claim 1 wherein the frame 
receiver further includes a filtering block for filtering frames. 

5. (Previously Presented) The hardware system according to claim 1 wherein the frame 
receiver further includes a retry operations block for determining when retransmission of a 
particular frame is needed. 

6. (Previously Presented) The hardware system according to claim 1 wherein the frame 
transmitter includes an acknowledgement block for determining that a particular frame was 
anticipated and sending an acknowledgement message corresponding thereto. 

7. (Previously Presented) The hardware system according to claim 1 wherein the frame 
transmitter further includes a special frames generation block. 

8. (Previously Presented) The hardware system according to claim 7 wherein the special 
frames generation block includes means for generating beacons. 

9. (Previously Presented) The hardware system according to claim 1 further including a 
timer block that controls timing for frames that are sent from and received by the system. 

10. (Previously Presented) The hardware system according to claim 9 wherein the frame 
transmitter includes a transmit state machine, the frame receiver includes a receive state machine, 
and further including: 

a cyclic redundancy code block that receives frames from the receive state machine and 
the transmit buffer and sends frames to the transmit state machine. 

11. (Previously Presented) The hardware system according to claim 9 wherein the frame 
receiver further includes a filtering block for filtering frames. 
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12. (Previously Presented) The hardware system according to claim 9 wherein the frame 
receiver further includes a retry operations block for determining whether retransmission of a 
particular frame is needed. 

13. (Previously Presented) The hardware system according to claim 9 wherein the frame 
transmitter includes an acknowledgement block for determining that a particular frame was 
anticipated and sending an acknowledgement message corresponding thereto. 

14. (Previously Presented) The hardware system according to claim 9 wherein the frame 
transmitter further includes a special frames generation block. 

15. (Previously Presented) The hardware system according to claim 14 wherein the special 
frames generation block includes means for generating beacons. 

16. (Previously Presented) A hardware system for performing media access control 
functions between a host central processing unit and a network, the system comprising: 

a buffer interface that sends frames to the host central processing unit and receives frames 
from the host central processing unit; 

a frame transmitter that includes a transmit buffer that receives frames from the buffer 
interface and sends frames to the network; 

a frame receiver that includes a receive buffer that receives frames from the network and 
sends frames to the buffer interface; and 

a timer block that controls timing for frames that are sent from and received by the 
system, the timer block thereby controlling interframe spacing and timing. 

17. (Previously Presented) The hardware system according to claim 16 wherein the frame 
transmitter includes a transmit state machine, the frame receiver includes a receive state machine, 
and further including: 

a cyclic redundancy code block that receives frames from the receive state machine and 
the transmit buffer and sends frames to the transmit state machine. 
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18. (Previously Presented) The hardware system according to claim 16 wherein the frame 
receiver further includes a filtering block for filtering frames. 

19. (Previously Presented) The hardware system according to claim 16 wherein the frame 
receiver further includes a retry operations block for determining whether retransmission of a 
particular frame is needed. 

20. (Previously Presented) The hardware system according to claim 16 wherein the frame 
transmitter includes an acknowledgement block for determining that a particular frame was 
anticipated and sending an acknowledgement message corresponding thereto. ' ~ 

21. (Previously Presented) The hardware system according to claim 16 wherein the frame 
transmitter further includes a special frames generation block. 

22. (Previously Presented) The hardware system according to claim 21 wherein the special 
frames generation block includes means for generating beacons. 

23. (Previously Presented) The hardware system according to claim 16 further including an 
encryption/decryption block that sends and receives frames between the transmit buffer and the 
receive buffer. 

24. (Previously Presented) The method according to claim 2 wherein the time critical 
function of formulating time-critical responses includes formulating an outgoing response frame 
for transmission to the network. 

25. (Previously Presented) The method according to claim 24 wherein the time critical 
function of formulating an outgoing response frame includes transmitting the outgoing response 
frame to the network. 

26. (Previously Presented) The method according to claim 25 wherein the hardware 
operations for transmitting the outgoing response frame include generating a special frame. 
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27. (Previously Presented) The method according to claim 26 wherein the special frame 
includes a beacon. 

28. (Previously Presented) The method according to claim 26 wherein the hardware 
operation of formulating an outgoing response frame includes receiving an incoming frame from 
the host central processing unit corresponding to the outgoing response frame. 

29. (Previously Presented) The method according to claim 2 wherein the time critical 
functions implemented by hardware operations include decrypting the incoming frame. 

30. (Previously Presented) The method according to claim 2 wherein the time critical 
functions implemented by hardware operations include determining whether retransmission of a 
particular frame is needed. 

3 1 . (Previously Presented) The method according to claim 2 wherein the time critical 
functions implemented by hardware operations include determining whether a particular frame 
was anticipated and sending an acknowledgement message corresponding thereto. 

32. (Previously Presented) The hardware system according to claim 1, wherein the buffer 
interface, frame transmitter, frame receiver and encryption/decryption block implement certain 
functions of a media access control (MAC) sublayer in accordance with IEEE 802.11. 

33. (Previously Presented) The hardware system according to claim 16, wherein the buffer 
interface, frame transmitter, frame receiver and timer block implement certain functions of a 
media access control (MAC) sublayer in accordance with IEEE 802.1 1. 

34. (Previously Presented) The method according to claim 2, wherein the time-critical 
functions comprise certain functions of a media access control (MAC) sublayer in accordance 
with IEEE 802.11. 
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35. (Previously Presented) The hardware system according to claim 1, wherein the buffer 
interface, frame transmitter, frame receiver and encryption/decryption block are together 
comprised of a single integrated circuit. 

36. (Previously Presented) The hardware system according to claim 16, wherein the buffer 
interface, frame transmitter, frame receiver and timer block are together comprised of a single 
integrated circuit. 

37. (Previously Presented) The method according to claim 2, wherein the integrated circuit is 
comprised of a single integrated circuit. 
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